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Method of transmitting digital services over a network and device 

implementing the method 

The present invention relates to the transmission of digital services 
5 and, more specifically, services compliant with the DVB (Digital Video 
Broadcasting) standard. DVB defines a service as "a sequence of 
programmes under the control of a broadcaster which can be broadcast as 
part of a schedule" on a network normally of the broadcast type (terrestrial, 
cable or satellite), but also more recently on an IP type network, in other 
10 words a network supporting the Internet protocol (IP). The specification of 
the IP can be found in the RFC (request for comments) documents 
maintained by the IETF (Internet Engineering Task Force), under number 
791. 

15 The recognition of digital services offered by a network is 

standardized by DVB in the context of a satellite, cable or digital terrestrial 
transmission network. This standard is described in the document "Digital 
Video Broadcasting (DVB); Specification for Service Information (SI) in DVB 
Systems", published by the ETSI (European Telecommunication Standards 

20 Institute) under number ETSI EN 300 468. This document describes a set of 
tables containing information on the network, on the frequencies at which the 
data streams containing the services are transmitted, on the services 
offered, etc. The reader can also refer to the document "MPEG-2 system - 
ISO IEC 13818-1" for a definition of the transport stream format. A transport 

25 stream therefore contains audio data, video data, ancillary data such as 
subtitles, teletext or interactive applications in the form of elementary 
streams, and minimum mandatory signalling tables used to organize the 
content as a Network Information Table (NIT) enabling the other transport 
streams on the network to be found, the Program Association Table (PAT) 

30 and the Program Map Table (PMT) among others. These tables are 
multiplexed In the transport stream, the receiver being configured with the 
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data needed to connect to a first stream enabling it to receive these tables 
and to construct, from their content, a database containing the list of 
services offered by the network and the connection data needed to receive 
them. 

5 

With the expansion of digital bidirectional data networks, in particular 
the Internet, and above all the roll-out of high speed services, the technical 
capability to transmit audiovisual digital services over this type of network is 
now available. Also, private, high bit rate IP networks are being developed, 

10 for both corporate and home use. Within this context, DVB is working to 
standardize the broadcasting of DVB services over the IP networks. A 
working group called DVB-IPI (Internet Protocol Infrastructure) is in the 
process of finalizing a specification concerning the transport of DVB digital 
services over an IP network and, more specifically, the recognition of these 

15 services. The proposal as currently envisaged is described in the document 
"DVB-IP Phase 1 Handbook" under reference IPI2003-227. The solution, as 
currently envisaged by the working group, is oriented towards a separation 
between the broadcasting of the services in the form of transport streams 

^ containing a single DVB service on the one hand*and the information 

20 describing these services, available in the form of XML (extensible Markup 
Language) files accessible to the terminals on request, for example. The 
HTTP (Hyper Text Transport Protocol) can, for example, be used to retrieve 
these files. This solution seems natural because it exploits the bidirectional 
nature of the IP connection, as contrasted with satellite transmission, for 

25 example. In practice, standards such as DVB have been designed from the 
perspective of a unidirectional transmission network requiring all the 
information likely to be useful to a receiver to be transmitted permanently. 
The bidirectional nature of the networks considered means that a distinction 
can be drawn between the information useful for decoding the audiovisual 

30 service and the service description information. These two types of 
information that are conventionally included in a DVB stream are not used 
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synchronously by the receiver. Their transmission over the network may 
therefore be separated, so providing a bandwidth saving by the fact that the 
signalling information is transmitted only on request and not permanently in 
the audio and video channel. Furthermore, the provision of information on an 
5 IP type network via HTTP servers in the form of XML data files is the 
predominant solution broadly adopted on this type of network. 

However, this solution makes it necessary to develop a set of tools for 
generating and managing the servers offering this signalling information in 

10 XML format. In fact, at the present time, content broadcasters have a 
controlled infrastructure for transmitting MPEG-2 DVB services via satellite 
or cable. Since the adoption of this new signalling system means that new 
tools have to be developed in parallel with the existing system, operators 
have to make an investment and take a risk. Furthermore, terminals do not 

15 currently incorporate the tools needed to analyse this information, such as 
an XML analyser, for example. The incorporation of such tools in an 
inexpensive receiver may prove difficult and even impossible depending on 

the hardware resources available, such as processor power or memory. 

• > 

20 The invention provides a method of transmitting digital services over a 

bidirectional data network and, more specifically, the recognition of the 
services offered on the network by a receiver. This method, used in the DVB 
context, enables most of the production chain currently deployed for DVB 
services for satellite or cable to be reused. This method should also enable 

25 the bandwidth used for broadcasting information for service recognition to be 
limited. 

The invention relates to a method of recognition, by a receiver 
connected to a bidirectional network, of digital services on the bidirectional 
30 network which comprises a step in which the receiver connects to a first 
stream, a step in which the receiver extracts from said stream information on 
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the location on the network, on the one hand, of streams conveying the 
content of these services and, on the other hand, of separate streams 
conveying information describing these services, a step in which the receiver 
connects to at least some of the streams conveying the service description 
5 information to obtain information on these services and a step in which the 
receiver uses this information to construct a list, possibly unitary, of services 
available on the network. 

According to a particular embodiment of the invention, all the 
10 signalling tables relating to a service are contained in at least one stream 
other than the stream conveying the content of said service. 

According to a particular embodiment of the invention, the method 
comprises a step for testing the mapping between an identifier and a filter 
15 contained in the descriptor of a stream used to determine whether a table 
having this identifier is available in said stream. 

According to a particular embodiment of the invention, the first 
broadcast IP address and the first port number are entered by the user. 

20 

According to a particular embodiment of the invention, the first IP 
address and the first port number are obtained from the network by the 
receiver. 

25 According to a particular embodiment of the invention, the streams 

contain only a single DVB service. 

According to a particular embodiment of the invention, the list of 
services is included in the NIT contained in the stream available at the first 
30 broadcast IP address on the first port. 



WO 2005/069624 PCT/EP2005/050026 

5 

The invention also relates to a device having means of connecting to 
a broadcast IP address via means of connection to an IP network and means 
of decoding a DVB stream broadcast to this broadcast IP address, 
characterized in that the DVB stream decoding means have the capability of 
5 analysing an NIT, extracted from the stream, containing network descriptors 
suited to the IP network, and of connecting to each broadcast IP address 
described in said NIT to read in it a DVB stream and extract from it the 
information on the services offered on the network, preferably according to 
any one of the methods as defined above. 

10 

The invention also relates to a descriptor of a service for broadcasting 
a DVB stream for inclusion in an NIT, characterized in that it contains the 
broadcast IP address of a stream server and a port number to which said 
server broadcasts a DVB stream conveying the content of a service over an 
15 IP type network and at least one descriptor containing the broadcast IP 
address of a stream server and a port number to which said server 
broadcasts a DVB stream conveying signalling information relating to said 
service. 

20 According to a particular embodiment of the invention, the one or 

more descriptors containing the broadcast IP address of a stream server and 
a port number to which said server broadcasts a DVB stream conveying 
signalling information relating to said service also contain the means of 
testing the mapping between an identifier and a filter. 

25 

The invention will be better understood, and other features and 
advantages will become apparent on reading the description that follows, the 
description referring to the appended drawings, among which: 

Figure 1 represents a diagram of the DVB service production chain 
30 within the context of a conventional satellite broadcast; 
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Figure 2 represents an example of DVB data stream architecture 
within the context of one exemplary embodiment of the invention; 

Figure 3 represents an example of DVB data stream architecture 
within the context of one exemplary embodiment of the invention; 
5 Figure 4 represents the operation of a receiver within the context of 

one exemplary embodiment of the invention; 

Figure 5 represents a diagram of the DVB service production chain 
within the context of one exemplary embodiment of the invention; 

Figure 6 represents the structure of an NIT (Network Information 
1 0 Table) according to the DVB standard; 

Figure 7 represents the structure of a standard digital decoder, for 
example in the case of terrestrial reception; 

Figure 8 represents the structure of a digital decoder suited to 
reception over IP; 

15 Figure 9 represents a flow diagram of the service recognition phase; 

Figure 10 represents a flow diagram of the service information 
reading phase. 

The exemplary embodiment of the invention relates to the 
20 transmission of DVB services over an IP network, but can be applied to any 
other system of transmitting digital services over a bidirectional data 
network. 

The connection to a server on an IP type network can be achieved 
25 using an IP multicast protocol. One example of such a protocol is the IGMP 
(Internet Gateway Management Protocol) defined in RFC 2236. In that 
protocol, a multicast server has an associated multicast address. This 
address has the format of an IP address, in a domain reserved for this 
purpose, but does not correspond to the IP address of a machine that can be 
30 accessed on the network. A receiver wishing to connect to this server will 
send a request over the network containing this multicast IP address. This 
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request will be relayed throughout the network until it reaches the server 
responsible for this broadcast, which will then register the receiver as a 
broadcast client. The routers on the path between the server and the 
receiver will then be able to relay the IP packets that make up the stream to 
5 the terminals subscribing to the broadcast. By knowing the IP address of the 
server machine in addition to the multicast IP address, an enhanced version 
of this protocol can optimize the route taken by the subscription request by 
routing it directly to the destination server instead of broadcasting it 
throughout the network. This enhanced version is known by the name SSM 

* 

10 (Source Specific Multicast). It is therefore a system based on subscription to 
a digital data broadcast. A server broadcasts the digital data, in packet form, 
over the network. As long as no receiver subscribes to this broadcast, no 
packet is actually transmitted. When a receiver subscribes, the packets are 
transmitted to it by a routing through the network following a route between 

15 the server and the client. The protocol makes sure that the packets will use 
only the routes of the network that lead to receivers that are actually 
subscribing to the broadcast. When a receiver unsubscribes, the actual 
transmission of the packets to this receiver stops. The protocol also makes 
sure that the packets are not duplicated over a route portion of the network 

20 that leads to several receivers subscribing to the broadcast. 

The transmission of the data that makes up the service can also be 
performed using an IP unicast protocol. One example of such a protocol is 
the real time streaming protocol (RTSP) defined in RFC 2326. Since this 

25 protocol is used to control the broadcasting of the stream over IP, it is 
designed to operate jointly with a broadcast protocol proper, such as RTP, 
the main difference from the multicast system being that for each client 
wishing to connect to the stream the server will initiate a point-to-point 
broadcast between itself and the client. Obviously this solution is more 

30 bandwidth-intensive than the multicast-based solution. In practice, in this 
solution, the data packets travelling over a route portion of the network that 



WO 2005/069624 



8 



PCT/EP2005/050026 



leads to a number of subscribing receivers are duplicated as many times as 
there are subscribing receivers. This solution can be considered in the 
context of a restricted network in which only a small number of terminals are 
likely to connect to a stream. 

5 

To limit the bandwidth used on broadcasting DVB services over an IP 
network while limiting the modifications to be made to the service production 
chain used by the broadcasters already offering services of this type on 
other transmission carriers such as satellite or cable, we will adopt an 

10 organization of the data forming the services as follows. On the one hand, a 
so-called installation stream will contain a table of information on the 
network closely derived from the DVB NIT and only this table, which we will 
call modified NIT in the sense that it uses the same syntax as the DVB NIT 
but contains specific descriptors, suited to the broadcasting of DVB services 

15 over IP. Moreover, the services will be separated into a content stream that 
will combine the elementary audio, video, subtitle and other service streams, 
as well as the minimum signalling used to organize these elementary 
streams such as the PAT and the PMT, and into a description stream 
containing only service description information. Only the content streams will 

20 retain the transport stream format as defined by MPEG-2. The installation 
and description streams are directly made up of tables such as the NIT for 
the installation stream and the SDTs or other tables for the description 
streams. These tables use the syntax of the MPEG-2 sections. In practice, 
access to the service description information is a one-off requirement not 

25 correlated to the need to decode the audio and video content. The current 
bandwidths on IP and the need to limit the bandwidth on the network make it 
probable that a stream will be created for each service, but the multiplexing 
of a number of services on a single stream is possible within the context of 
the invention. 
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To adapt the NIT to use on an IP network, descriptors suited to 
locating streams on an IP network must be defined. Such a descriptor suited 
to multicast use is given below: 



10 



15 



20 



25 



30 



Syntax 

Ip_stream_descriptor () { 
Descriptor_tag 
Descriptor_length 
Con ten t_mul t icas t_addre s s 
Content_nvulticast j>ort_number 
Content_multicast_protocol_mapping 
Con ten t_ source_address 
For (i«0; i < N; i++) ( 



No of identifier bits 



8 
8 

32 
16 
8 

32 



uimsbf 

uimsbf 

bslbf 

bslbf 

bslbf 

bslbf 



Descriptor () 



The "Descriptorjag" field is an identifier corresponding to this new 
type of descriptor. 

The "Descriptorjength" field gives the length of the descriptor 

The "Content_multicast_address" field is the multicast IP address of 
the server on which the content stream is available. 

The "Content_multicast_port_number ,, field is the port number on the 
server to which the receiver must connect to receive the content stream. 

The w Content_multicast_protocoLmapping n field is a field identifying 
the encoding protocol of the or each service broadcast to this address. The 
protocol can be MPEG-2, MPEG-4, MHP or another. This optional field can 
be used to filter by content type to retain only those services that the 
receiver is able to decode. 

The "Content^soure^address" field is the real IP address of the 
server that provides for efficient routing of the connection request to a 
multicast server according to the SSM protocol. 

The loop on the descriptors is used to manage the location 
descriptors of the or each description stream relating to the service, the 
content of which is broadcast to the previously defined address. 
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Below is a definition of another example of such a descriptor suited to 
unicast use: 



10 



Ip_stream_descriptor () { 
Descriptor_tag 
Descriptor_length 
Content_unicast_address 
Content_unicast_port_number 
Contentunicast_protocol_mapping 
For (i-0; i < N; i++) { 
Descriptor () 

) 

) 



8 
8 

32 
16 
8 



uimsbf 

uimsbf 

bslbf 

bslbf 

bslbf 



15 



20 



25 



30 



The "descriptorjag" field is an identifier corresponding to this new 
type of descriptor. 

The "descriptor Jength" field gives the length of the descriptor. 

The "Content_unicast__address n field is the unicast IP address of the 
server on which the stream conveying the content is available. 

The "Content^unicast^port.jnumber^ field is the port number on the 
server to which the receiver must conned to receive the stream conveying 
the content. 

The "Content_unicast _protocol_mapping" field is a field identifying 
the encoding protocol of the or each service broadcast to this address. This 
protocol can be MPEG-2, MPEG-4, MHP or another. This optional field can 
be used to filter by content type to retain only those services that the 
receiver is able to decode. 

The loop on the descriptors is used to manage the location 
descriptors of the or each description stream relating to the service, the 
content of which is broadcast to the previously defined address. 



We will see in the structure of the DVB NIT, and therefore of the 
modified NIT, that there is a loop on the transport streams, which means that 
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10 



alt the transport streams that make up the entire network of a broadcaster 
can be described in this loop. In this way, the receiver can construct a list 

with the multicast or unicast IP addresses of all the transport streams of a 

» 

broadband TV broadcast over IP network. A list of service descriptors can 
optionally be included in the modified NIT to speed up the receiver 
installation phase. 

Multicast and unicast stream servers present in the same network can 
also be envisaged. 

* 

In another, more sophisticated, implementation, the location 
descriptors of the information description streams relating to the transmitted 
service can, for example, take the following form: 



15 ip_stream_multicast_locator_descriptor () { 



20 



Descriptor_tag 

Descriptor_length 

Filter_length 

Filter_descriptor ( ) 

multicast address 

mu 1 t i c a s t_po r t_numbe r 

multicast j>rotocol_mapping 

source address 



8 
8 
8 

32 
16 
8 

32 



uimsbf 
uimsbf 
uimsbf 

bslbf • 
bslbf 
bslbf 
bslbf 



25 



30 



Here, we find the conventional fields of a descriptor for locating a 
stream broadcast over IP in multicast mode. Only the "Filterjength" and 
"Filter^descriptor fields merit an explanation. In practice, within the context 
of the illustrative embodiment of the invention, the service description 
information is separated from the content information, and is conveyed in a 
single different stream. Yet, it is also possible to convey this signalling 
information, i.e. these tables, in a plurality of different streams. It is precisely 
to take this possibility into account that the "lp_stream_descriptor" descriptor 
contains a loop. Yet, when this descriptor is scanned, it is not necessarily 
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known which stream in the loop of descriptors will contain a given table that 
is being sought for the service affected by the descriptor. The act of 
introducing the "Filterjength" and "FilterjJescriptor" fields in the descriptor 
makes it possible to implement a means of storing in the descriptor 

5 information for ascertaining which tables are contained in each stream of the 
loop. One way of encoding this information can, for example, be to place in 
this n Filter_descriptor" field the strings of bits used, for example, to program 
a demultiplexer to filter said tables. Since each table type has a given 
identifier, the filter can be programmed with the bit string representing the 

10 identifier of the table contained in the stream. In cases where it is desirable 
to be able to have a number of tables in the stream, the method used to 
program the filter of the demultiplexer can be adopted. A first bit string 
indicates an identifier that is to be filtered and a second string of the same 
length indicates for each bit of the first string whether that value is defined or 

15 not. A given identifier will therefore correspond to the filter if, for each bit of 
this identifier for which the corresponding bit of the second bit string is at 
one, the corresponding bit of the first string has the same value. For 
example, if strings on three bits are considered - a first bit string with a value 
of 0b101, a second string with a value of 0b110 - the identifiers 

20 corresponding to this filter will have the values 0b101 and 0b100. This 
method can be used to define the tables contained in the stream in the same 
way as a demultiplexer would be programmed to retrieve them. 

In another, simpler implementation, the location descriptors of the 
25 information description streams relating to the broadcast service can, for 
example, take the following form: 

Ip_stream_multicast_locator_descriptor_taLble_ids () { 

Descriptor_tag 8 uimsbf 

30 Descriptor_length 8 uimsbf 

NbOfTablelDs 8 uimsbf 
TablelDList () 

multicast address 32 bslbf 
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mu 1 1 i c a s t _po r t _n umbe r 
multicast_protocol_mapping 
source address 



16 



bslbf 



8 



32 



bslbf 
bslbf 



> 

5 Here, we find the conventional fields of a descriptor used to locate a 

stream broadcast over IP in multicast mode. Only the "NbOfTablelDs" and 



TablelDLisf fields merit an explanation. 

The "tablelDLisr field corresponds to a list of table identifiers which 

10 are included in the corresponding stream, and the "NbOfTablelDs'' field 
represents the number of table identifiers listed. Thus, a stream containing 
both information relating to the signalling information on the current and 
subsequent events of the current stream, for which the table identifier is 
0x4E, and the signalling information on the current and subsequent events 

15 of the other streams, for which the table identifier is 0x4F, will have a 
descriptor with the value 2 for the "nbOfTablelds" and the values 0x4E and 
0x4F in the "tablelDList" field. 

Another possibility of implementing the broadcasting of the streams 
containing the signalling information may be to choose a simple file transfer 

20 protocol between the server and the receiver instead of the multicast 
protocol. Such a protocol can, for example, be the hypertext transfer protocol 
(HTTP). This protocol is simple to implement, especially if it is limited to 
implementing the capability to perform a "GET" to obtain a file from a server. 
This protocol is far simpler to manage than the XML file processing 

25 described in the introduction. In this case, it is important to have another 

« 

descriptor such as the descriptor below, which is used to link, to a given 
identifier table, the URL (universal resource locator) of the file containing it: 

Ip_stream_HTTP_locator_descriptor <) { 
30 Descriptor tag 8 uimsbf 



Descriptor_length 
Table_id 

For (i=0; i<N; i++) { 



8 



uimsbf 



8 



bslbf 



Char 



8 



bslbf 
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However, this method is not the preferred embodiment of the 
5 invention, because broadcasting by HTTP, just like in the unicast 
transmission of these signalling tables, involves a duplication of the data 
stream on the network for each receiver wanting to be installed. Yet, it is 
nevertheless an embodiment that can be considered on networks that do not 
contain many receivers, such as domestic networks. 

10 

Figure 1 describes the general architecture of an MPEG-2 DVB 
service production chain within the context of a satellite broadcast. At the 
start of the chain, there is the audio and video content 1.1 that is to be 
broadcast. This content is encoded according to the MPEG-2 standard in an 

15 encoder 1.2 to generate an elementary audio/video stream 1.5. In parallel 
with the encoding of the audio and video content, the signalling information 
1.3 is generated, which normally originates from a database containing the 
information describing the service that is to be broadcast. This information is 
generated in the form of a signalling stream 1.6. Another module 1.4 handles 

20 the generation of a subtitle stream 1.7. It is also possible to include an 
interactive application stream 1.8, the production chain of which is not 
detailed here. All these elementary streams, with other streams if necessary 
conveying other audio and video contents, the related or other signalling, 
are then multiplexed in a multiplexer 1.9 to generate the MPEG-2 transport 

25 stream that will then be modulated and converted to a frequency chosen by 
the modulator/converter 1 .10. A set of streams of this type can be mixed by a 
mixer 1.11 for transmission to a satellite 1 .13 via a transmission station 1.12. 
In this case, synchronization of the signalling information is necessary 
between the various streams to include information on the other streams in 

30 the tables describing each stream. These programmes can then be received 
in the home of the user via the tetter's dish antenna 1 .14, to be decoded by a 
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set-top box and displayed on a television. This system is now well within the 
capabilities of broadcasters. 

Figure 2 represents an example of stream architecture according to 
5 an exemplary embodiment of the invention. In this example, a first stream 
2.1, called an installation stream, is shown. This installation stream contains 
no audio or video content, but only the modified NIT 2.4 containing the 
network information. This installation stream can directly use the syntax of 
an MPEG-2 section and need not feature encapsulation in the form of a 
1 0 transport stream because of the fact that the data is directly transmitted over 
the IP network. 

This modified NIT describes a number of streams containing services. 
The standard structure of an NIT as defined by DVB is given in Figure 6. 

15 Although a stream, regardless of the transmission means, can contain a 
number of DVB services, it is probable that only the streams containing only 
one DVB service will be used initially in the context of broadcasting over IP, 
for reasons of bandwidth. The example described in Figure 2 therefore 
reflects this case. However, it is obvious that the invention is not limited to 

20 the use of streams containing only one DVB service in the stream. We 
therefore have in the modified NIT 2.4 a description of three services 2.5, 2.6 
and 2.7. The description of a service will contain the descriptors 2.8 and 2.9 
for locating the content stream 2.2, as well as the stream containing the 
description relating to the service 2.3. The content stream 2.2 will contain a 

25 PAT (Program Association Table) pointing to the contents relating to a 
service 2.11 made up of a PMT (Program Map Table). The description 
stream 2.3 is therefore a separate stream from the preceding one. This 
stream does not have the format of the MPEG-2 transport streams but, 
directly, tables having the syntax of an MPEG-2 section. This separation 

30 enables a client to connect to this stream only when it needs to access the 
description information and therefore avoids using the bandwidth for 
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permanent transmission of this information. Thus, the use of this bandwidth 
is improved. Remember that in broadcasting over IP, when a receiver 
unsubscribes from a broadcast, the actual transmission of the packets over 
the network to that receiver stops. In the example, the description stream 
5 contains the information on the events 2.14, such as the information on the 
current event, the next event, and, where appropriate, the complete calendar 
of events so that an electronic program guide can be constructed. It also 
contains the information on the service 2.13, such as the SDT (Service 
Description Table). 

10 

Figure 3 is another example of stream architecture according to an 
exemplary embodiment of the invention. This example is very similar to the 
preceding one as represented in Figure 2. The difference lies in the fact that, 
in this case, the description information relating to the events and the 

15 information relating to the service are conveyed by two different streams. We 
therefore in this case have, for the service 1 3.5, three screen descriptors 
3.8, 3.9 and 3.10 instead of the two preceding ones pointing to the content 
stream 3.2, the service information stream 3.3 and the event information 
stream 3.15. It is therefore possible to divide up the different tables that 

20 make up the signalling information over different streams according to the 
available tables and the use that will be made of them to manage the 
network bandwidth. It is also possible to take the service management 
constraints into account by grouping together tables having the same update 
frequency. 

25 

Figure 4 represents a diagram showing players describing the phase 
of recognizing services present on the network. The entities represent on the 
one hand the user of the system who is watching his receiver, the receiver 
and the installation, service content and service description streams. Other 
30 streams relating to other services may be present in the network but are not 
shown in the figure. Initially, the user switches on his receiver. The receiver 
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then connects to the installation stream. The receiver has parameters 
enabling it to connect initially to a multicast or unicast IP address. The 
simplest solution is to assume that this broadcast IP address is entered 
manually in a configuration menu. This broadcast IP address can also be 
5 assigned to the receiver in the connection phase via protocols such as 
DHCP (Dynamic Host Control Protocol) or PPP (Point to Point Protocol). 
However, any other method of determining this first IP address is possible. 
This address consists of a multicast or unicast IP address and a 
corresponding port number. The installation stream is broadcast to this 
10 address. 

Once the receiver is connected to the installation stream, it can 
therefore decode the modified NIT and read the information contained in it. 
The receiver is therefore able to create a list of services available on the 

15 network. Scanning this list gives it access to the broadcast addresses of the 
content streams and the description streams broadcast over the network. 
This receiver can therefore connect in turn to these streams to collect the 
information on the services, including the name of each service. This means 
that it is then possible, for the* receiver, to present a list of the services to the 

20 user. The user then chooses the service he wants to watch, and the receiver 
uses the descriptor of the content stream found in the modified NIT for the 
chosen service and connects to the content stream of the chosen service. 
The decoding and display of the chosen service can then begin. If the user 
then wishes to access the information on the current event or on the next 

25 event, he sends a request to that effect, and the receiver will once again use 
the descriptor contained in the modified NIT to find therein the location on 
the network of the description stream containing the information on the 
events. This information may be contained in the same stream as the service 
description information or in a separate stream as described in Figures 2 

30 and 3. The receiver then connects to this stream and retrieves the 
information on the events so that it can display the information to the user. 
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The receiver can be connected to a stream, for example, via the 
IGMP. Normally, this transport stream is of the encapsulated MPEG-2 over 
IP type using the IP/UDP/RTP (User Datagram Protocol, Real Time Protocol) 
5 layers, but it can also be an MPEG-4, MHP or other type stream. 

Figure 5 represents the stream production chain according to the 
invention. Firstly, the raw audio and video content 5.1 is encoded by the 
encoder 5.4 to give the elementary audio and video streams 5.7. A database 

10 5.2 contains the entire description of the services and the information on the 
events. A module 5.5 is used to construct the signalling tables 5.8 with this 
information. The signalling information 5.8, the audio and video content 
streams 5.7, and other optional information such as interactive or other 
applications 5.6 are multiplexed 5.9 to construct a content stream 5.10. A 

15 first formatting module 5.1 1 uses the signalling tables 5.8 constructed, where 
appropriate, from information contained in the database 5.2 and additional 
information on other services 5.3 to construct the description stream 5.12. A 
second formatting module 5.13 uses the additional information on the 
network services 5.3 to construct the installation stream 5:14, which will 

20 contain the description of all the streams available on the network with the 
addresses providing access to them. The main modules that do not exist in 
the conventional DVB service production chain are these formatting modules 

5.11 and 5.13. However, these modules are simple to construct because 
they merely construct streams containing signalling tables such as those that 

25 are already constructed by the signalling module 5.5, the novelty originating 
from the use of descriptors suited to locating a stream on an IP network, 
whether this stream is transmitted in multicast or unicast mode or even 
available via a file transfer protocol such as HTTP. These streams, 5,10, 

5.12 and 5.14, once constructed, can then be transmitted to the servers of 
30 the IP network. 
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Figure 7 describes the architecture of a conventional decoder, such 
as a digital terrestrial decoder. The decoder 7.1 has a screen 7.3. The user 
7.2 interacts through a browser application 7.4, which is displayed on the 
screen 7.3. All the decoder functions are driven by a management 

5 application conventionally referred to as middleware 7.5. This management 
application drives the hardware modules, namely the tuner 7.8, the 
demultiplexer 7.7 and the decoder 7.6. The tuner is responsible for 
recovering the DVB stream received by the antenna 7.9. This stream is 
demultiplexed by the demultiplexer, in other words the demultiplexer is able 

10 to reconstruct the different elementary streams that make up the DVB 
transport stream, such as audio, video and auxiliary data (such as subtitles, 
teletext or an interactive application) or a particular signalling table. In the 
DVB stream, each elementary stream is identified by an identifier and a 
demultiplexer can be programmed to filter the elementary streams that are of 

15 interest to us from the complete stream that is received. At least the audio 
and video streams are encoded to compress and/or encrypt the information 
that they contain, and the decoder is therefore there to decompress and/or 
decrypt these streams to restore the audio and video content to the user. 

20 Figure 8 describes an IP decoder, designed to receive DVB streams 

over an IP network. The architecture is exactly the same as in the case of 
the conventional decoder, apart from the fact that the tuner is replaced by a 
network interface 8.1 0 connected to an IP network 8.1 1 . 

25 Figure 9 details the steps in recognizing services on the network. The 

first step consists in obtaining the installation stream 9.1. This stream is 
available on the network. There are many ways of making this stream 
available, of which at least three can be cited, and this stream can be 
transmitted in multicast mode, and can also be transmitted in unicast mode 

30 or be available via a file transfer protocol such as HTTP, for example. 
Regardless of how this installation stream is broadcast over the network, the 
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decoder needs to be able to retrieve it, so it needs to know the address and 
the connection parameters for connecting to this stream. This first address 
can either be present in the read only memory of the device or be 
communicated to it by the user or even be communicated to the device by a 
5 server on connection to the network via a connection protocol enabling 
parameters to be acquired, such as DHCP (Dynamic Host Configuration 
Protocol) or PPP (Point to Point Protocol). The receiver is connected to the 
installation stream 9.2, and then searches it for a modified NIT 9.3. When 
this modified NIT is found, it reads in this modified NIT the description of a 

10 first transport stream characterized by its transport stream identifier (TSID) 
and its origin network identifier (ONID) 9.4. Then, since a transport stream 
can contain a number of services, the receiver starts reading the description 
of the services contained in the transport stream. For each service, the 
receiver begins by reading the service identifier and the data for locating the 

15 content stream 9.5. For each service, information on this service can be 
contained in a plurality of service description streams. The location of this 
plurality of description streams is specified in a series of descriptors that are 
now read 9.6 and 9.7. Then, for each service, the transport stream identifier, 
the origin network identifier, the service identifier, the location descriptor of 

20 the stream conveying the content of the service (CSL standing for "Content 
Stream Locator"), as well as the table of Service Description Stream 
Locators (SDSL) 9.8 are stored. These operations are repeated for each 
service contained in the transport stream as well as for each transport 
stream 9.9 and 9.10. In this way, a list of all the services available on the 

25 network is obtained, together with the descriptors of the streams 
broadcasting them both for the content and for the content description 
information. 

Figure 10 details an example of the way in which the information on 
30 the services can be recovered once the list of services has been constructed 
by scanning the modified NIT as explained in Figure 9. To recover the 
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information on the various services offered on the network, the receiver must 
find the Service Description Tables (SDT) for each service. To do this, it 
begins by reading the descriptor of the first service 10.1. It then reads the 
first Service Description Stream Locator (SDSL). Then, if this SDSL does not 
5 contain the "Filterjength" and "Filter_descriptor fields providing information 
on whether the designated stream contains the SDT, it must connect to the 
stream 10.9, read from that stream the sections in search of an SDT for 
which the table identifier is 0x42, 10.10, 10.11 and 10.12. In the case where 
the "Filterjength" and "Filterjjescriptor" fields exist, it will use these items 

10 of information to check for the presence of the SDT in the stream 1 0.3. If it is 
not present, it tests the next descriptor 10.13, 10.14 and finishes by deleting 
from the list a service for which it would not be able to find the SDT 10.15. 
When it has found the stream containing the SDT, it reads this table 10.5 
and finds in it the name of the service and of the service provider, which it 

15 stores in memory 10.6. This operation is repeated for all the services 10.7, 
10.8, up to the end of the list of services 10.16. 

The invention enables broadcasters to re-use most of their existing 
production chain, in particular the multiplexers. The only development 

20 needed is that of formatting modules, for constructing streams containing 
only signalling tables, all or part thereof, and, where appropriate, not 
encapsulating them in a transport stream. This development is minimal. The 
invention also limits the modifications to be made to the software run on the 
decoders. In practice, mainly the part managing the IP interface, instead of 

25 the satellite or cable reception interface, has to be added, whereas the part 
of the application managing the installation has to be slightly modified. All 
the rest of the operation of the device is the same as for a standard decoder. 
Similarly, access control can be reused identically. The invention therefore 
makes it possible to adopt the broadcasting of DVB services over a 

30 broadband IP network while minimizing the investments and risks for 
broadcasters and the use of the available bandwidth on the network. 



